Aminet 4

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 4 / Aminet 4 - November 1994.iso / aminet / comm / bbs / c342p22.lha / 68k.man next >

Wrap

Text File | 1994-03-12 | 65KB | 1,302 lines

Citadel-68K System Related Notes --------------------------------- The Citadel-86 documentation is generally applicable to Citadel-68K for the Amiga. However, there are some features which the Citadel-68k do not supported, Some will eventually be worked on, and other may never get done. In general you can get help on Citadel 68K by calling one of the following Citadels: The Amiga Zone: 609-953-8159 Images 612-884-7951 Full Circle 612-827-3214 C-86 Test System 612-470-9635 You also can call most any local Citadel and post messages in the Citadel 68K room or the Amiga room. Both rooms are netted to the Amiga Zone and will eventually reach me. I have spent a fair amount of time on this document, cannot guarentee everything... If you find an error, please let me know. I suggest that if you are thinking of starting a Citadel BBS, you should first become familar with a local sysop of a Citadel BBS. Next, get a separate phone line for the BBS alone. If you run a BBS and it is not a 24 Hour BBS, you will find few callers. Next, decide what kind of theme your BBS will have. A theme will attract callers. Now, you need to see if you have the resources to run a BBS. I have seen big systems and small run Citadel. 2 floppies plus 512K is barely enough to survive. Since the Amiga multitasks, you can do other things while the BBS is running. I would recommend a minimum of 1 megabyte of memory plus at least 3 floppies or a hard drive. You can run a Citadel on less, but probably will not last long with only a few messages and rooms. I would recommend 2 MB of memory and a 20 MB HD to most Citadels as the "normal" configuration. I have 7 MB of RAM and 110 MB of Hard drive. The more memory the better, I get problem reports from people with the "minimum" RAM that I truely think are due to lack of memory. Also, while Citadel is compatible with 1.3 and beyond, I run with 2.1 AmigaDos and there have been reports of problems with external program(protocols, doors) with 1.3 based systems. Lastly, get the lastest Citadel, Documenation files and spend about a week reading this and the other Citadel documenation. You will be confuse and probably will not understand most of it. Now take the ctdlcnfg.sys from the archive(if you did not find one in your archive, get the real thing from one of the systems above) and change the appropriate parameters. The file is called "examples.sys" so that existing sysops do not clobber their current setup. Set things up and go on the air. Once you have had a few callers, been working on your BBS and feel confortable with it's operation, check with local citadel sysops and connect up to the network. You will have to find out who is the "local feed" in your area, just ask any sysop. Make your arrangements and changes to the ctdlcnfg.sys and you will be connected coast to coast. I suggest that you make an attempt to get the Amiga and Citadel 68K rooms shared with your system. I and other Sysops will post information on upgrades and problems. Remember, Every Sysop was in your shoes at one time or another. We all started out the same way. We are all pretty much a friendly bunch(no matter how much we argue on the net!) and are glad to help. When you connect up to either room, place what is called a seed message telling everyone who you are,where you are located, and your Node ID. You might be surprised who might give you a call(me for one!).... Good Luck! INSTALL3.MAN ------------ o Later on in this manual is a list of some of the parameters that you can control. All the configuration parameters are documented either in the INSTALL3.MAN or later in here. o Ignore all references to the EASE utility. Currently, the only Amiga Ease program that exists does not work. It has been given low priority over other things. Eventually, I will get to it. o Ignore references to supported machines and operating systems. Citadel-68k is for the Amiga line of products. o Ignore references to DOS configuration. INSTEAD -- you must make sure you have STACK 20000 in your Amiga setup. Citadel requires it. It really only uses about 6K, but this is to be safe. o Section II.6.b -- when specifying directories for system data files (like #MSGAREA, etc.), you may use either relative or absolute directory specifications, rather than being constricted to subdirectories of the current directory. o Parameters not supported in Citadel 68K #IBM #COM #OLDVIDEO #FOREGROUND #BACKGROUND #STATUS-FOREGROUND #STATUS-BACKGROUND #SEARCHBAUD o Ignore Sections II.10.b, II.10.c, II.10.d.1, II.10.e, and Section III. OPER3.MAN --------- o Section VIII.4 (File Transfers while in Chat Mode) references the PC's PG UP and PG DN keys as primary methods to download and upload in chat. Since the Amiga has no such keys, you must use the alternative described -- CTRL-E for Uploads, CTRL-F for downloads -- if you use Citadel for BBSing at all. Performance in Chat mode is not good when calling other bulletin boards. I recommend you use something like terminus instead. o Section VIII.7 is not correct for the Amiga. o Section XII (Outside Editor) is implemented but works a little oddly. If you are using an editor like TURBOTEXT that will release the starting process, it will not work correctly. With TURBOTEXT, use the commands #EDITOR "TTX WAIT" #EDIT-AREA "CIT:temp/" This way it will hold up the process and CTDL will be able to get the file AFTER you changed it. Without the "WAIT" it does not work correctly. o The Multiple banners seems to confuse the budding sysop. Here is how it works. If you create a directory called BANNERS, Citadel will look for the NOTICE, LONOTICE, BANNER, and NOCHAT banners in that directory first, and if it does not find one there, it will use the default banner from the helps area. The banners display as follows: -- Carrier is detected -- Display Banner.PRE <-- only one of these in helps area Display Banner.BLB or .NN <-- If .NN exists else do .BLB -- User Login -- Display Notice.PRE <-- only one of these in helps area Display Notice.BLB or .NN <-- If .NN exists else do .BLB Display Notice.SFX <-- only one of these in helps area -- User Logout -- Display LoNotice.PRE <-- only one of these in helps area Display LoNotice.BLB or .NN <-- If .NN exists else do .BLB Display LoNotice.SFX <-- only one of these in helps area In addition to these banners, the NOCHAT.BLB can be replaced with the appropriate NOCHAT.NN for when chat is disabled. OTHER NOTES ----------- o The Read forward command has two parameters which may be substituted for the date. These are YESTERDAY and TODAY. The commands would look like: .RF TODAY or .RF YESTERDAY Also instead of the date(i.e. 92APR02), you may specify the number of days to go back with: .RF 5 <-- Read forward from 5 days ago. o There is an AREXX port in Amiga Citadel. The AREXX capabilities of Amiga Citadel are limited to execution of simple instructions. The port name of the program is "Citadel68K". These instructions are as follows: "setchat" 0/1 -- sets chat mode "setecho" 0/1 -- sets echo mode "setnouserdisable" 0/1 -- sets Call Sysop flag "exit" 0/1 -- forces ctdl to exit with 1 bypassing protection to keep from kicking off users. "version" -- returns version of program "serialenable" 0/1 0/1 -- enables/disables serial.device with the second parameter determining if the program should override protection to prevent a user from getting kicked off. I plan to add other AREXX command to Citadel 68K as people request them(if they are possible to do). o There are Amiga Specific commands in Ctdlcnfg.sys. These are: #WBENCHWINDOW -- Placing this in the file tells ctdl to open a window on the workbench screen rather than create a new screen. The next two paramaters work differently based on the presence or absence of this paramater. #SCREENWIDTH n -- Describes the width of the screen when a new screen is created. Otherwise it describes the width of the window created by the program on the workbench screen. #SCREENHEIGHT n -- Describes the height of the screen when a new screen is created. Otherwise it describes the height of the window created by the program on the workbench screen. #SCREENCOLOR0 n -- The background color (pen 0) of the screen that ctdl opens. This is the RGB value broken down in binary expressed as a decimal number. This number is created by the pattern 0000rrrrggggbbbb. Example Red Intensity 8 is 2048. #SCREENCOLOR1 n -- The foreground color (pen 1) of the screen that ctdl opens. This number works the same as screencolor0. #DISABLEEHO -- if this parameter is present, console echo will be disabled upon startup of ctdl. #DIRECTTOCHIP -- if this parameter is present, serial output will be directed directly to the chip that handles serial I/O, bypassing the serial.device. This should work for all systems and is only a selection because of choice. System Setup: The following files are mentioned in the other manuals, this is just a summary for the budding sysop. These files are created by CONFG unless otherwise noted. Some you will create to add features to Citadel. o CTDLMSG.SYS. This file contains all the messages in the system. o CTDLROOM.SYS. This file contains information about the rooms in your system. The size of this file is given later in this manual. o CTDLLOG.SYS. This file contains all the accounts for users on your system. The size of this file is given later in this manual. o CTDLNET.SYS. This file, if it exists, will be 0 bytes long when initially generated by CONFG.EXE. o CTDLFLR.SYS. This file contains information about the floors in your system. This is the only file of this group is not static; it grows as you add floors to your system. Don't panic, though. Each floor only takes 21 bytes. o CTDLARCH.SYS. This file contains data about auto-archiving of rooms (an advanced topic to be covered under day-to-day operations). o CTDLNET.SYS. This file, created by CONFG, will be expanded by CTDL if you are participating in a network. o CALLLOG.SYS. This file, an optional text file, is updated as each caller hangs up. This will be placed in the #CALLAREA o CTDLDIR.SYS. This file contains data about the directory rooms on your system, specifically the name of the DOS directory associated with each directory room on your system. Optional items I will not say too much about these since they are optional and not needed to startup your system. They are covered in detail in the other manuals. o CTDLPROT.SYS If this file exists, it contains information about external protocols. To get Zmodem for example, you need to file a Zmodem program(See P340.lzh) and add the information to this file. o RESULTS.SYS This file specifies your modems response codes. You really should have one of these that looks something like: #result-300 Connect 300 #result-1200 Connect 1200 #result-2400 Connect 2400 #result-9600 Connect 9600 #no-dialtone No Dialtone #no-carrier No Carrier #ok OK #error Error #voice Voice #busy Busy #ring Ring Without this file, CTDL will work, but you get improved performance with it. You can cut this section out of this file, remove the leading spaces and use it as is. The "#" start in col 1. CONFG PARAMETERS: To setup a Citadel, you have to create a file called CTDLCNFG.SYS. It is read by CONFG and all the other files are created. The most confusing part of being a sysop is setting up this file. The parameters here are explained in enough detail so you can setup your system. Use the example file in the archive to setup all the details. #nodeTitle "<title>" The first parameter you should find is called nodeTitle. It is a string value that obeys formatting directives, and is subject to formatting considerations. nodeTitle is the title of your installation that is printed when is detected on your system. More precisely, nodeTitle will show up in the following place on your system: Welcome to <title> Running ... However, nodeTitle may not necessarily be printed at this point, because if a help file named BANNER.BLB exists on your system, it will be printed in place of the "Welcome to <nodeTitle>" part. EXAMPLE: #nodeTitle "Test System\n Truly a Heaven in Reverse" The #nodeTitle is printed out on .Read Status commands, also. There is no formal limit on the length of this parameter, but you should definitely use BANNER.BLB for long #nodeTitles, or to vary it easily. #nodeName "<nodename>" nodeName is, in reality, purely a network parameter, and if you have no plans to ever join a C86net, then there is no need to fill in this parameter. However, it has always been traditional, even before there was a net for any Citadel system anywhere, to fill in this and the next parameter (and, so, sentimentally we feel this belongs in this Miscellaneous section). nodeName is a string value which does NOT accept formatting directives (i.e., formatting directives will be ignored). It can be no longer than 19 letters long. It should be a short, mnemonic name for your system. An EXAMPLE of a reasonable value: #nodeName "ODD-DATA" If you ever do join a C86net, messages from your system appearing on another Citadel node of that net will look something like this: 82Nov23 from Cynbe ru Taren @ODD-DATA except that ODD-DATA would be replaced with your value for #nodeName. #nodeId As mentioned, this parameter is a network parameter that has traditionally always been set, even for non-network Citadels. If you have no plans to ever be on a C86net, then you don't have to set this string value parameter to anything important. If you do plan to join one, though, (we'll go over this in more detail in the section on the network), then you do have to set this parameter correctly. The format of this parameter is "<Country code><Area Code><Phone number>" all of which applies to the phone that your system resides on. Country code is a two letter sequence indicating what country you live in (US is the United States, CA is Canada. Area code is the area code of your system (yes, we are aware that there is a clear bias towards US-style telephony). And Phone number is, of course, the phone number that your system is on. You can put punctuation (such as parenthesis and dashes), but please be conservative with them. This string value does not obey formatting directives. Here's a fairly generic example: #nodeId "US (609) 953 8159" #baseRoom "<firstRoom>" OK, now we're into parameters that you must have set, starting with baseRoom. Citadel always has a minimum of three rooms, the Aide> room for housekeeping, the Mail> room for private correspondence, and the <baseRoom>, which is the room that a caller is always initially placed in. (Historical note: the old CP/M Citadel called this room the Lobby>; we've only made the name of the Lobby> selectable by the sysop.) This parameter is a string value that obeys formatting directives and goes through the Citadel formatter, and you must limit yourself to 19 characters or less for this value. And one more note, Citadel will append the '>' to this name when it prints the room prompt for this room, you don't have to put it in yourself. If you wished to emulate the old CP/M Citadel, you'd set baseRoom thus: #baseRoom "Lobby" There is no default for this parameter. #MainFloor MainFloor is analogous to #baseRoom. Any Citadel has a base floor, just as it has an Aide> room, etc. This parameter allows you to name this base floor. This parameter is a string value which cannot be longer than 19 characters, and specifies the name of your base floor. So, if you want to name your base floor MAIN FLOOR, you'd have #MainFloor "MAIN FLOOR" There is no default value for this parameter. #CRYPTSEED <number> Citadel automatically encrypts all sensitive data files. While the algorithm used can, of course, be broken by the determined, particularly since the code is available for perusal, the encryption does provide protection against casual eyes, mistakes, and amateur system breakers. We do encourage you to take precautions of your own, such as not opening directory rooms that look at sensitive data. Encryption can be disabled if you specify a value of zero. You may use any value 0-65536. CRYPTSEED is an encryption seed that Citadel uses to encrypt your data; if someone should acquire of all of your data files but for CTDLCNFG.SYS, then they still won't have access to your system until they figure out what your CRYPTSEED is. DON'T EVER CHANGE THIS VALUE WHILE RUNNING A CITADEL, OR EVERYTHING WILL BECOME MESSED UP! If you are rebuilding your system from scratch, you may change the value at that time. An example: #CRYPTSEED 69 #MESSAGEK <size in K> MESSAGEK defines how much disk space you wish to allocate for messages on your installation. There is no way to define how many messages you want in your system, or how fast they turnover. All the messages in your system will reside in CTDLMSG.SYS, and thus the number of messages in your system at any given moment will depend on the length of the messages being entered into the system by your users. The turnover rate of your messages will depend on how busy your system is. As an example, Test System has a 611K message base, which holds 2100 messages +/- 300, of which some are of fairly good length. Turnover seems to between 3 weeks and a month, since 80-160 messages are entered a day. However, Test System is also a busy system. The sysop of an installation should also keep in mind that very large systems, with many new messages, can be intimidating to new users, so large message spaces should be approached with caution. Remember, there is a utility for expanding the message base, but not for shrinking it. This is a numerical value which you specify in 'K', which is actually 1024 bytes/K. So, for example, to specify a 250K message file. #MESSAGEK 250 -- 250K message base #MSG-SLOTS This numerical parameter specifies how many messages per room will be used on this system (the lone exception is the Mail>, which is covered by the following parameter). If you wanted to use Citadel's traditional number of messages per room, you'd have #MSG-SLOTS 58 #MAIL-SLOTS This is a numerical parameter specifying how many messages per log record that you wish to reserve for Mail. The Mail> room is the only room in the system whose data is not kept in CTDLROOM.SYS. Instead, the file CTDLLOG.SYS contains the "Mail>" room, reserving for each account enough room for MAIL-SLOTS Mail messages. Therefore, this parameter gives you the ability to decide the maximum number of Mail> messages per user that they can access. Please remember that if a user gets more messages in Mail> than there are MAIL-SLOTS between two successive logins, then they will lose the earlier messages sent to them. Another consideration is that many users like to review old Mail when engaged in an in-depth private conversation. Therefore, setting MAIL-SLOTS to a low value may not be the attractive alternative that it first seems. However, it should go without saying a high MAIL-SLOTS value may eat up more room than necessary on your drives. The section on LOGSIZE will give an exact formula for how much space your log will take up. Example: #MAIL-SLOTS 58 #MAXROOMS This numerical parameter specifies the maximum number of rooms your system will support. Since the baseRoom, Aide>, and Mail> room are necessary, the smallest value you can give is 3. The largest number is 65536 (probably). If you wanted to have a 64 room system, you'd have #MAXROOMS 64 You can use the following formula to estimate the number of bytes a room file will take up on your system: # of bytes = MAXROOMS * (50 + (6 * MSG-SLOTS)) #LOGSIZE This numerical parameter gives you, the sysop, the ability to decide how many accounts will be available on your system. If you run a system in which more accounts are used than there are accounts reserved, then new accounts are generated by killing old accounts. The account that will be replaced with the new account is that account which has not been used in the longest time (in other words, accounts that are not used will be the first to be killed). All space is reserved immediately for these accounts. The size of this file can be estimated from the formula: # of bytes = LOGSIZE * (82 + MAXROOMS + (6 * MAIL-SLOTS)) so if you are operating in a restricted environment, plan accordingly. If you need to, you can expand the size of the log through the use of the DATACHNG utility, but the log cannot be shrunk. This is a numerical value. Here is an example: #LOGSIZE 180 Now we discuss where you want the data files to be located on your system. These parameters are all specified in the same way, as a string value (which does not obey formatting directives, naturally) that tells Citadel where on your system the given data file or files associated with the given parameter is located. Simply use either a relative directory specification or a full pathname. So, some sample valid specifications would be "c:", "a:system", b:msgs", and "i:bark". If CONFG cannot find the directory that you specify, it will attempt to create that directory, after asking permission. #HELPAREA "cit:helps" This parameter specifies where all of your Help files will be located. These files are *.HLP, *.BLB, and *.MNU. Normally, you should create this directory and place the help files in the directory before bringing up Citadel, since help files are usually online at all times. The Help files are maintained on Test System. Ask any Citadel System where to find them. I also have a set on the Amiga Zone. #LOGAREA "c:system" This parameter specifies the location of your CTDLLOG.SYS file (this file is sized by your LOGSIZE parameter). #ROOMAREA "system" This parameter specifies the location of CTDLROOM.SYS, CTDLARCH.SYS, and CTDLDIR.SYS. #MSGAREA "c:msg" This parameter specifies the location of CTDLMSG.SYS. #FLOORAREA "floors" This parameter specifies the location of CTDLFLR.SYS. #AIDESEEALL This parameter is a toggle that gives you some power over the scope of your aides' "vision". If you set this parameter to 1, then your aides have access to all public AND private rooms (but not invite rooms, unless they have been invited). If this parameter is set to 0, then aides only have access to public rooms, plus those private and invite rooms that they've been invited to. So, if you want your aides to see all public and private rooms, you would have #AIDESEEALL 1 -- See all but invite rooms if you don't want your aides to be so nosy, then you'd have #AIDESEEALL 0 -- See only public rooms. #LOGINOK The LOGINOK parameter controls whether your system is an "open" or "closed" system. If you set LOGINOK to 1, the system will allow anyone to log in as a "new" user; that is, it will ask a caller who uses an unrecognized password if they wish to login as a new user. If LOGINOK is set to 0, the system will simply tell the caller without a valid password that there is no record of that password, and that they should leave Mail> to the sysop; the only way to enter new users into the system is from the system console. If you want an open system, for example, you would have: #LOGINOK 1 -- let the riff-raff in! #ENTEROK ENTEROK controls whether a caller who is not logged in can enter messages or not. If ENTEROK is 1, then a caller who has not logged in can enter messages; if it is 0, then they must log in first, except for Mail to the sysop. Setting ENTEROK to 0 can reduce vandalism; setting it to 1 gives your callers the privilege of anonymity. #ENTEROK 0 -- log in first, folks! #READOK READOK controls whether an unlogged caller can read messages. If READOK is 1, then they may. If READOK is 0, then an unlogged caller can only read the policy statement available in the Mail> room (POLICY.HLP), and the help files. Setting READOK to 0 can discourage unwelcome callers from using scarce system time. #READOK 0 -- gotta login to read these gems... #ROOMOK ROOMOK controls who can create new rooms on your system. If ROOMOK is 1, then any logged in user of the system may create new rooms. If ROOMOK is 0, then only aides may create new rooms on your system. #ROOMOK 1 -- a liberal policy #ALLMAIL ALLMAIL controls who can use the Mail> room. If ALLMAIL is 1, then any user may use Mail> to send private messages to any other user on the system. If ALLMAIL is 0, then only Aides may use the Mail> room in a general manner; regular folk can only use Mail> for messages to Sysop. Setting ALLMAIL to 0 may be appropriate on tightly focused systems operating in a small environment. #ALLMAIL 1 -- the normal policy #SYSBAUD The SYSBAUD parameter is used to tell Citadel what baud rates your hardware will support. Citadel cannot normally be configured to run high baud rates while excluding lower baud rates (i.e., operate correctly at 1200 baud but not at 300 baud). A value of 0 indicates that the system is a 300 baud system, 1 indicates 300/1200, 2 indicates 300/1200/2400, 3 indicates 3/12/24/48, and 4 indicates 3/12/24/48/96. #SYSBAUD 1 -- A 3/12 system. #SEARCHBAUD if you are a novice, we suggest setting this parameter to 1, even if you do have an internal hayes modem. only play with the searchbaud parameter after you have a CITADEL installation that works correctly. The SEARCHBAUD parameter is used to tell Citadel how to find the baud rate of the caller. If the value of this parameter is 1, then Citadel will search for the correct baud rate by switching through each of the valid baud rates for this installation, searching for a half second at each baud rate for a carriage return from the caller. If the value of this parameter is 0, then Citadel assumes that you have a failure-proof method of detecting the baud rate of the caller. Most modems today will handle the detection of the baud rate and send a result code. #SEARCHBAUD 1 -- Normal setting #modemSetup This parameter is used to initialize your modem. It is a string value parameter that obeys the formatting directives; however, you should be warned that Citadel automatically appends a "\r" to the end of this string before sending it to the modem. And when is modemSetup sent to the modem? It is automatically sent twice while Citadel is initializing, and it will also be automatically sent to the modem whenever the <R>einitialize command is selected from the Sysop Menu ( i.e. privileged function:). The value that you use for this string should cause the modem to be put into a mode where it will function suitably with Citadel. This includes auto-answer and response to DTR, at the very least. Other options that you may wish to consider include turning the modem speaker off (if you have one); consult your modem manual for details. The example we have here is biased towards Hayes/compatible modems. You may have to do some research if you're using an odd modem. Our example turns auto-answer on and turns off the speaker on a Hayes modem; note the lack of "\r". #modemSetup "AT S0=1 M0" -- Surely an exercise in aesthetics... #event <days> <time> <class> <type> <duration> <warning string> <depends> This is what we're calling a "time-driven event-handler", which we're going to define as the ability to cause Citadel to do certain things at times that you specify. So, for instance, you can have the system come down at certain times of the day to back itself up, or have it go into networking mode several times a week -- or several times a day. Or do whatever your imagination suggests. Any number of these #event parameters may appear in your CTDLCNFG.SYS file. Here is an explanation of each parameter field in the above statement. <days> can be any of the values "Mon", "Tue", "Wed", "Thu", " Fri", "Sat", "Sun", or "All", or any combination of the first seven. If used in combination, separate each with a ',', but NO spaces are allowed. This part of #event is used to specify on what days this event is to take place. So, if you want something to happen only on Wednesdays and Saturdays, then you'd have #event Wed,Sat .... The 'All' value means, of course, all days of the week. <time> is the military specification of what time of day this event is supposed to happen (unless the class of this event is 'relative' -- see below). For instance, 11 AM would be: #event .... 11:00 .... while 11 PM would be: #event .... 23:00 .... and 12:30 AM would be: #event .... 00:30 .... Only one time can be specified in this field. If you need the same event to happen at multiple times, then use separate # event entries. <class> indicates the class of the event, which is roughly what kind of event it will be. Citadel supports four classes of events at this time: 'network' -- this indicates that Citadel should drop into networking mode on the day(s) at the time indicated by the <days> and <time> fields. 'external' -- this indicates that Citadel should come down on the day(s) at the time specified by the <days> and <time> fields. The ERRORLEVEL that Citadel should generate when it comes down will be discussed later in the subsection on the <depends> field. This class should be used in conjunction with a carefully written batch file. 'relative' -- this indicates that Citadel should come down X minutes after it has come up (this is used to replace the TIMEOUT and HOUROUT parameters). The number of minutes should be expressed in the <time> field; the <days> field has no meaning (although it must be filled in) when class is 'relative'. The ERRORLEVEL to be generated by Citadel when it comes down will be discussed later, but for now we'll state that it occupies the <depends> field. For instance, if you want your system to come down 6 hours after it comes up, do something, and then come back up (at which point you should realize it'll come back down again 6 hours after that, unless another event comes first), you would have an event like: #event Sat 6:00 relative .... 7 in your CTDLCNFG.SYS (note that Sat is meaningless, but some valid value for the field has to be there). 'dl-time' -- This indicates that a "download time limit" should be activated. This was a recent addition to the #event handler, and is thus a patch rather than a full-scale addition; to truly implement a download time limit would probably require a Major Release. When this class of event is active, the total amount of time a user may use in downloads during a session is limited by the value in the <depends> field, which is designated in MINUTES. This class value should only be used with the 'quiet' type (see below). When this event ends, download time limits return to an unlimited status automatically. <type> defines what type of event this will be, which essentially means how Citadel reacts when the event time comes around. There are two types of events supported at this time: 'preempt' -- this indicates that when it's time for this event to occur, the current user (if one is on) will be kicked off the system. A warning will be issued to the user 5 minutes before the event is to occur (or if they call in after the 5 minute mark has passed, they will get the warning immediately). This type should be used for events that MUST occur at a given time, such as networking. 'non-preempt' -- this indicates that the system is willing to wait until the current user is off the system before executing the current event. If the time of the event is passed by, the event will still be executed when the caller logs off. 'quiet' -- this indicates that the event should occur with no notice given to the user. Currently, this only makes sense with the 'dl-time' parameter, since there is no need to bring the system down or drop into network mode to change the dl-time limit. <duration> defines how long the event will last, in minutes. If duration is 0, then if you happen to bring the system up at the exact time that the event is to take place, the event WON'T take place; for all other values of duration, the event will take place. Duration should probably be 0 for external events that you only want to happen once, happen quickly, and bring the system right back up, such as a backup event in which your script file backs up the system and then brings it back up. This can go so fast that your system will be back up in less than 1 minute, so you don't* want duration set to 1 -- you want it at 0, otherwise the event could be executed more than once. However, for network events you certainly want it set correctly. A 45 minute network event would look like this: #event ... ... network preempt 45 .... <warning string> is only valid for 'preempt' events. It is sent to the user for the warning and for the "you've been kicked off" messages. It should be enclosed in quotes. Here's what the messages look like: "<beep>WARNING: System going down at <time> for <warning string>." "<beep>Going to <warning string>, bye!" So, for networking, #event .... "networking" ... works just fine. <depends> is a parameter whose meaning depends on the class of the event. If the class of the event is 'external' or ' relative', then this value is the ERRORLEVEL that Citadel is supposed to generate as it comes down, and should be used in Script files for further processing. The upper effective limit on this parameter is whatever AmigaDOS allows in Script files. Before leaping into this, however, please review the section on Script files in the Manuals, paying particular attention to already-reserved ERRORLEVELS. If the class of this event is 'network', then <depends> specifies what net(s) this network event is going to participate in. While we are not going to discuss in detail what Citadel's " multinet" capability is, here is a summary: Citadel supports handling multiple C86nets. Each network is identified by a number; all of the nodes in your system can be associated with 0 or more of these nets. Thus, using the <depends> field can allow you to network with certain systems at one time and/or day, and other systems on other times and/or days. The <depends> field must have at least one of the nets identified here, and may have more if a particular network session is servicing more than one network at a time. If more than one net is to be serviced, place a comma, and ONLY a comma, between each net identifier. So, if you wanted to specify nets 1, 6, and 14, you'd have: #event .... 1,6,14 If the class of the event is 'dl-time', then the depends field specifies the maximum number of minutes that may be spent in downloading during a single login while this event is in effect. And that's it for the #event parameter(s). We hope our explanation is understandable; we sure had a hard enough time writing it! #sysPassword This parameter gives you access to the Remote Sysop capabilities of Citadel. A "Remote Sysop" is an Aide, not at the System Console, who knows the Remote Sysop Password. A Remote Sysop's capabilities include complete access to the Sysop Menu (yes, including such silly things as changing the Baud Rate ) and when editing rooms the Remote Sysop can do what a normal Sysop can do. A Remote Sysop gains access to the Sysop capabilities in exactly the same way as a normal Sysop does, by sending a ^L to the system -- but a Remote Sysop has to supply a password. This parameter, a string value that does not obey formatting directives, does NOT (repeat NOT!) specify the Remote Sysop Password. Rather, it specifies the NAME of a file that contains, on one line, the Remote Sysop Password (this allows you to hide your Remote Sysop Password somewhere on your system). This filename may specify any file anywhere on your system, including different drives and subdirectories. The password itself must be at least 15 letters long, and is, unlike most passwords, case-sensitive. WARNING: If you change the password in the file, you must run CONFG again ( CONFG ONLYPARAMS -- see the Section on Command Line parameters). If this parameter is not specified, or the file is not found, then the Remote Sysop facility will not be available. This password should be protected to the maximum extent possible. Major abuse is possible if some juvenile delinquent breaks two passwords. However, if you insist on using this facility, and placed your password in a file in a directory on partition G:, in a file named PWD in a directory on the root called HIDING, you'd have the following in your CTDLCNFG.SYS file. #sysPassword "g:hiding/pwd" At this point I would say something about security in general. If you leave your system files, ctdlcnfg.sys and other things directly available to your users, you run the risk of having someone download them and effectivly hacking into your system anytime they want. It would take no longer than the download and a run of a utility to know passwords of all your users and create havoc on a board. Please keep the files in a safe place that is only accessable by the Sysop locally. This is the first commandment of Security! Also do not give out AIDE privledges lightly. Make sure you can trust the person! #AUDITAREA This parameter is just like the MSGAREA, et al. It is a string value parameter that specifies a drive and directory which will hold an audit file. If this parameter is not present in your CTDLCNFG.SYS file, then the audit file will not be created or updated by Citadel. The audit file is known as CALLLOG.SYS. It is a simple ASCII text file that contains notes regarding system usage. There are only two types of notes. The first lists when the system has come up and down. The second type records who has called, listing login and logout times, one line per person, in the following format: <person> : <login time> - <logout time> <baud rate> Occasionally such a line will have an extra character appended onto it, and they have the following significance. '+' Means that this user logged in as new. '-' Means that this user used .TS to logout. 'T' Means that this user timed out on the system. 'E' Means that this user hit the error limit on the system and was kicked off. If you want to have a call log, you would have something like this in your CTDLCNFG.SYS file: #AUDITAREA "audit" -- This would be a subdirectory #MIRRORMSG The structure of Citadel's message base causes frequent disk access. While this is not particularly deleterious for a hard disk, this kind of activity has been known to actually destroy floppy drives. Therefore, it makes sense to put the message base into a RAM drive. However, this leaves systems vulnerable to message base loss due to power failure. Because of this, Citadel has the ability to support two identical message bases at once. The first message base functions as the primary; messages are written to and read from this base. This message base is specified by the MSGAREA parameter. The second message base, however, is subject only to writing, thus saving wear and tear on the media involved. Since the primary message base (the one that is both written to and read from) is subject to a lot of wear and tear, this message base should be placed in a RAM disk. The MSGAREA parameter mentioned earlier specifies the area for the primary message base. It is your responsibility to make sure that a copy of CTDLMSG.SYS is in the RAM disk when you bring Citadel up; Citadel will not do that for you. The secondary message base, since it is only written to, should reside on permanent media, such as a floppy. The parameter MSG2AREA, a string value that does not respond to formatting directives, specifies the area where the secondary message base should reside. Since both message bases are written to simultaneously, they should remain identical. If you wish to use this option, MIRRORMSG should be set to 1; otherwise, it should be set to 0. If MIRRORMSG is set to 1, then MSG2AREA should specify where the secondary message base should reside. For instance: #MIRRORMSG 1 -- yeah, why not? #MSG2AREA "b:msg" -- on floppy, of course #RESULT-300 #RESULT-1200 #RESULT-2400 #RESULT-4800 #RESULT-9600 #RING Citadel has the ability to read the result codes from Hayes compatible modems and determine the baud connection of the modem from them. The #RESULT-xxxx parameters and the #RING parameter are string values which should contain the result codes your modem will return for the respective connections, while #RING is the result code for a RING. Consult your modem for the exact values, since they vary from modem to modem. You are also responsible for using the #modemSetup parameter to initialize your modem correctly for returning result codes. When Citadel is trying to use result codes to detect the baud rate of a caller, it proceeds by scanning the input for a C/R. Once one is found, then the characters accumulated before the C/R are compared to your #RING value. If they are identical, then all the characters are thrown away and Citadel looks for more result codes. If #RING did not match, then the system will scan the various #RESULT-xxxx values that you specified, again looking for a match. If one is found, then the respective baud rate is set and the system proceeds with login. If a match is not found, then the system begins scanning for user-sent C/Rs in an attempt to find the baud rate. You do not need to specify values for baud rates your modem doesn't support, and we recommend that you do not. If you have your SEARCHBAUD parameter set to 0, then you should NOT use this option. Here is an example for a MultiTech MT224. #RESULT-300 "1" #RESULT-1200 "5" #RESULT-2400 "9" #RING "2" Earlier in this document is a copy of a typical RESULTS.SYS file which will work for most any Hayes compatible modem. #HOLDAREA Citadel has the optional capability to save messages that are inadvertently interrupted during composition by users for later completion. The reason we say "optional" is that the method used to save such messages is to save them as files on disk, and in a restricted environment such an ability may not be desirable. Thus, this feature is only available on systems in which #HOLDAREA is defined. #HOLDAREA is another directory specification, exactly like those of Section 1 of CTDLCNFG.SYS. All messages that are interrupted will be stored there until the next time the user logs in. These files are currently 7706 bytes long. #HOLDAREA "hold" #sysopName This parameter is used to tell your system who the sysop is. The only real effect of this parameter is that all Mail> to sysop is automatically routed to the account that you specify in this parameter's string value. (This will also affect net Mail> to sysop.) If you're not using this parameter, or the account does not exist, then Mail> to sysop will end up in the Aide> room. #sysopName "Me!" #NETWORK This parameter controls whether or not you're in the network at all. Set it to 1, and you are. If it is set to 0, then you are not (initial setting for our virgin copy). If you are planning to participate in the network, then please be sure that you understand the section on the #event parameter, because that is what you use to tell your system when to communicate with other systems on the networks. Also contact the Sysops of the systems you plan to netword and tell them you NODEID and NODETITLE. You must also arrange the calling and many other parameters. The Sysops you contact can help you setup this and get it working. The Aide room will contain messages telling you of problems with your networking. #NETWORK 1 -- This system participates. #LONG-HAUL This parameter controls whether or not you'll ever call any systems that are long distance from you. If 1, then you will (if you have any on your list, natch); if 0, then you won't. Naturally, if you never have any systems that are long distance from you in your node list, your system will never call long distance. #LONG-HAUL 1 -- Sure, what da heck #NewNetPrivs This numerical parameter let's you decide if new users should automatically have net privileges or not. If 1, then they do; 0, they don't. #NewNetPrivs 0 -- let's be paranoid! #NETAREA This string parameter specifies where all the net files will be located on your system. The "net files" are CTDLNET.SYS and various temporary files that have the suffixes ML, RFL, and SFL. NETAREA is just like LOGAREA, MSGAREA, etc., specifying either a relative path name or full pathname. #NETAREA "netstuff" -- let's put it in a directory called -- netstuff. #SHARED-ROOMS This numeric parameter reserves room in each node record for the number of shared rooms you think you'd like to share. Each takes up 6 bytes, so plan according in view of the number of nodes you'll have on your node list and the number of rooms you might want to share with other systems. If you think you might add rooms later, make this large enough for your plans. #SHARED-ROOMS 4 -- conservative #NET-ARCH-ROOMS This numeric parameter reserves room in each node record for the number rooms that you think you'd like to archive via the network. Each takes up 6 bytes, so once again plan accordingly. #NET-ARCH-ROOMS 2 -- it's an odd capability #NET_RECEPT_AREA This parameter specifies a directory on your system that will contain all files that are sent to your system by some other system during networking, using the Send File facility (this is not the same as requesting files over the network). NET_RECEPT_AREA is a string value that does not obey string formatting directives, of course, and it may specify any directory on your system, not just a subdirectory to your current directory. So, supposing you wanted to specify Cit:CITADEL/HOLDING as the directory for incoming files from the net, you'd have in your CTDLCNFG.SYS #NET_RECEPT_AREA "Cit:CITADEL/HOLDING" -- that directory #NET_AREA_SIZE #MAX_NET_FILE These two parameters allow you to control how much space you wish to devote to files coming into your system from the net via the Send File command (i.e., other systems sending you files without you asking). NET_AREA_SIZE allows you to tell Citadel how much space to devote to the directory specified in NET_RECEPT_AREA. When a system attempts to send you a file, Citadel will get the size of the file, and then check to see how much space is already being taken up by files in NET_RECEPT_AREA. If the difference of NET_AREA_SIZE and the files already in NET_RECEPT_AREA is less than the size of the incoming file, then your system will not accept the file that is being sent to you. Make this large enough for expected files, but do not exceed the space on the drive/partition. MAX_NET_FILE allows you to control how big a file you will ever accept. If the size of the file being sent to you exceeds the value you specify here, then your system will not accept the file being sent. Both of these values are in terms of K. So, for instance, if you only wanted to allow files of up 24K into your system, and only wished to devote up to 44K to NET_RECEPT_AREA, you'd have: #NET_AREA_SIZE 24 #MAX_NET_FILE 44 #callOutPrefix #callOutSuffix These two parameters control modem dialing during networking. These are both string value parameters that will obey formatting directives, and should be used to convey commands to the modem. When dialing, Citadel constructs a phone number to send to the phone company, and sends the following to your modem: <callOutPrefix><phone#><callOutSuffix> callOutPrefix should alert the modem to dial, while callOutSuffix should do anything necessary to finish the dialing sequence (usually, just send a C/R to the modem). If you have a Hayes modem, we recommend you use the following values for these two parameters. #callOutPrefix "ATDT" -- Tells a Hayes modem to dial out using -- touch tones #callOutSuffix "\r" -- puts a carriage return at the end #LOCK-PORT This parameter allows you to lock the computer to modem data rate and have Citadel ignore the results code for user connections. This is used in conjuction with SERIAL_7WIRE when you have a high speed modem. #SERIAL_7WIRE This is a required parameter if you are using a computer to modem data rate that is greater than the user connect rate. If for example you have an MNP modem and have the computer locked at 9600 baud(See #LOCK-PORT above, you need that too). This enables the hardware handshaking CTS/RTS. If you do not do this, users will overrun the modem buffers at slow rates and see garbage. It is important to note that your system may have problems with high-speed. Typically the following is a good rule of thumb: System Configuration | Baud Rate Maximum ------------------------------+--------------------- A500, 512K, 2 Floppies | 9600 A2000, 2 Mbs, HD | 19.2K A2000, 2 Mbs, HD, Accelerator | 19.2-38.4K A3000 | 38.4K A4000/030/040 | 38.4K Basically, for systems with fast modems, set SYSBAUD and LOCKPORT to the same value, and use SERIAL_7WIRE. #SERIALDEVICE #UNITNUMBER These two parameters are of use to those with alternate serial devices, internal modems, third-party serial card. It allows you to name the device and unit number Citadel should use to communicate with your modem. #alldone This is the last parameter in the ctdlcnfg.sys file. It tells the CONFG program to finish processing and write the appropriate data files. When you run a CONFG, the output will echo all your commands and any errors. Watch it run and answer any questions. After it completes it will write the magic "ctdltabl.sys" file. This file is the controling file of Citadel. If for some reason it is lost, you will have to run CONFG again. Now all that remains is to run CTDL in the manner you decide. If CTDL DIDN'T come up, there are a large variety of reasons for the failure. If your system seemed to make it up but came down relatively gracefully (i.e., left you at the system prompt), check your disks for a file named CRASH. It may give you (or the person you turn to for help!) a hint on what might be wrong. If it seems to think there's an error with a file, perhaps you forgot to configure correctly. If CTDL itself complains about "no ctdltabl.sys!", then either that file isn't on your default disk when you called CTDL, or CONFG didn't successfully finish. Let's go over exactly what will happen. When you run CONFG, it should go through CTDLCNFG.SYS. Once finished, however, it's behavior will differ. It should not ask you if it may create the appropriate directories (since they should already exist), and it should not complain about not being able to find any of your system files (these should still exist, too!). However, it WILL ask you if you wish to erase and initialize your system files. This time reply N (with vigor!). CONFG will immediately begin analyzing your data files, and after several minutes, depending on the size of your system, it will produce a CTDLTABL.SYS; your system will be fit to run again. CTDL when run, will process the command line options(see below) and then proceed to eat the CTDLTABL.SYS file. When it is done you no longer have one! Not to fear, when you do an orderly shutdown(sysop menu, X option for eXit), it will be re-created. CTDL options The options starting with a "+" are switches that enable/disable some function of citadel. This is a summary of the supported options: +netlog - Citadel will log all network activity in netlog.sys +nochat - Citadel will chat with nobody when chat is off. +netdebug - Citadel will provide additional info on networking +nomeet - Disables the User biographies +noecho - Disables the User echo on the console +vortex - Enables the vortex detection +vandaloff - Disables the checks for unlogged vandals +conpwd - Makes you use the sysop password at your console +noconban - controls the system banner at login The other options supply a parameter. The format is option=parameter. There are no spaces around the "=". kip - Not sure what this is for... Have to look???? lowfree= - Sets the minimum free space on the upload disks lddelay= - Sets the connection time Citadel will wait for a connect on long distance calls. paranoia= - specifies the number of messages a user may leave in a room. If exceeded the user is dropped. bps= - For use for those sysops using the #ISDOOR parameter zmodem= - Flag to control fast transfer enable.